faternet Addresses and some OL files for 
Your Computing Fun 


by GHRIS FOWLER 


lf anyone's interested in the Internet, here are two sites with QL- 
further sub-directories, 


related files. Entries beginning with "d" are 


Internet server: maya.dei.unipd.it Sub-directory: pub/pub/sinclair_QL 


README 
C68 
C68.version4 
CLUBS 
COMPRESS 
DMES3 
DOCS 
FSH_v2 
HARD_DISK 
KERMIT 
NEWZOO 
QHJ 
QLDB3 
QLSCR41 
QLTOOLS14 
QLUTIL 
QUILL2ASCII 
ROGUE 
SCHEME 
TIFF 
XLISP 


A help file for the mail se 


-{'WRXI--f-- 
Crwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 
Crwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 
Crwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 


1106 10 
2106 100 
2106 100 
2106 10 
2106 10 
3106 100 
2106 10 
3106 100 
2106 100 
2106 100 
2106 1 
2106 100 
2106 10 
2106 100 
2106 100 
2106 10 
2106 100 
2106 100 
2106 100 
2106 10 
2106 100 
2106 1 


76 Dec 14 1992 
512 Jun 15 15:36 
512 Oct 23 09:38 
512 Jun 1614:58 
§12 Oct 13 1992 
512 Jan11 1993 
612 Jun 14 08:31 
512 Apr 20 1993 
512 Nov 25 1992 
512 Dec 28 1992 
512 Oct 13 1992 
512 Apr20 1993 
§12 Oct 13 1992 
512 Oct 13 1992 
512 Oct 13 1992 
512 Oct 13 1992 
512 Oct 19 17:06 
512 Mar 4 1993 
512 Oct 19 17:01 
512 May 17 11:52 
512 Feb 15 1993 
512 Oct 19 17:02 


garbo. uwasa. fi 


Welcome to University of Vaasa, Finland 


MAIL SERVER INFORMATION 
garbo-request PC PD archive mail server 


rver at garbo.uwasa.fi can be requested by sending a ’send help’ 
message, or a null message, to mailserv@garbo.uwa 
request’. (Don’t include the quotes "). 


sa.fi with a subject line of 'garbo- 


* TO REPEAT: The Subject-line of the message MUST say * * ’garbo-request'.* 


Internet server: garbo.uwasa.fi Sub-directory: ql 


-TW-TW---- 
QLINDEX -TW-TW-r-- 
Onews-ql -W-IW-r-- 
QLINDEX -TW-1TW-r-- 
QLUPLOAD. INF drwxrwxr-x 
basprog drwxrwxr-x 
basrout Crwxrwx-wx 
incoming drwxrwxr-x 
lis drwxrwxr-x 


its 
its 
its 
its 
2ts 
2ts 
2ts 
2ts 
2ts 


staff 
staff 
staff 
staff 
staff 
staff 
staff 
staff 
Staff 


4634 Oct 17 12:52 . 


9997 Oct 17 12:55 
4724 Oct 17 12:53 
1404 Sep 27 05:19 
1024 May 6 17:31 

512 May 6 17:32 

512 Aug 16 12:40 
1024 Oct 17 12:53 


512 May 6 17:31 pas 
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a 
Motorola 68060 Microprocessor 
a ee 


by Joe Circello and Floyd Goodrich 
Microprocessor and Memory Technology 
Group Motorola Inc. 


This article originally appeared in the IEEE 
Journal with illustrations and was down- 
loaded from the QL Fidonet 


The Motorola 68060 is the fourth generation 
microprocessor of the M68000 Family. User object 
code compatible with previous family members, it 
delivers 3 to 3.5 times the performance of the pre- 
vious generation processor in this family, the 68040. 
Performance features include a superscalar integer 
unit, ahigh-performance floating point unit, dual 8 
Kbyte on-chip caches, a branch cache, and on- 
chip memory management units. A streamlined de- 
sign enables high-performance techniques to 
achieve a high level of parallel instruction execu- 
tion. Improved performance at a low cost makes 
the 68060 an ideal processor for the mid to high 
range of desktop computing applications, and 
compatibility features enable itto easily upgrade 
performance of existing 68040-based systems. 
This paper describes the operation of the 68060. 


Introduction and Overview 


The 68060 is the fourth generation micropro- 
cessor of Motorola's M68000 Family of CISC micro- 
processors. It is a single-chip implementation that 
employs adeep pipeline, dual-issue superscalar ex- 
ecution, a branch cache, a high performance float- 
ing point unit (FPU), 8 Kbytes each of on-chip in- 
struction and data caches, on-chip demand paged 
memory management units (MMUs), These fea- 
tures allow it to achieve execution rates of less than 
one clock per instruction sustained execution. 
In order to meet the performance goals of the 
68060, instruction execution times needed to de- 
crease, and parallel operations needed to increase 
over previous generations of M68C00 microproces- 
sors. A superscalar instruction dispatch micro- 
architecture is the most obvious feature of this in- 
creased parallelism on the 68060. Superscalar 
architectures are distinguished by their ability to 
dispatch two or more instructions per clock cycle 
from an otherwise conventional instruction stream. 
In addition to the superscalar features, this single 
chip has many other performance, upgrade and 
system integration features including: 


* 100% user-mode object code compatibil- 
ity with 68040 * Dual-issue superscalar in- 
struction dispatch implementation of 
M68000 architecture, * IEEE Compatible 
on-chip FPU * Branch Cache to minimize 
Pipeline refill latency * Separate 8 Kbyte 
on-chip instruction and data caches with 


simultaneous access * Bus Snooping 
* 68040 compatible bus Protocol or new 
high-speed bus protocol * 32-bit nonmulti- 
plexed address and data bus * Four-entry 
write buffer * Concurrent operation of In- 


_teger Unit, FPU, MMUs, caches, Bus Con- 
‘troller, and Pipeline * Sophisticated power 


management subsystem * Low-power 3.3V 
operation * JTAG Boundary Scan 


Design Targets 


The design goals of the 68060 included provid- 
ing a simple upgrade path for existing M68000 
Family designs while also supplying a basis for 
Motorola's successful 68ECOx0 Family of embed- 
ded controllers and for the 68300 Family of modular 
integrated controllers. 


Initial requirements for the targeted 68060 
were to provide a factor of three performance en- 
hancement over a 25 MHz 68040 with existing 
compiler technology. Architectural enhancements 
were to provide at least a 50% improvement while 


‘doubling clock frequency doubles performance. 


The performance estimates reflect analysis of exist- 
ing object code; additional performance advan- 
tages are, of course, available when using compi- 
lers designed specifically for the 68060, 


In addition to software compatibility, the 68060 
preserves the investment in board-level ASICs by 
providing bus compatibility with the 68040. This 
supersocket approach facilitates upgrade of all ex- 
isting and future 68040-based systems, 


The 68060 uses approximately 2.4 million trans- 
istors. The partis a static CMOS design based ona 
0.5 um triple level metal wafer process, This pro- 
cess will enable the 68060 to operate at a 3.3 volt 
power supply-- a greater than 50% power reduction 
over a 5.0 volt power supply. Since the 68060 mi- 
nimizes power dissipation through a variety of archi- 
tectural and circuit techniques, it is able to offer 
high performance processing to the laptop and 
portable markets in addition to the traditional com- 
puter-system markets. 

Architectural Features 


The architecture of the 68060 revolves around 
its novel integer unit pipeline. Taking advantage of 
many of the same performance enhancements 
used by RISC designs as well as developing new 
architectural techniques, the 68060 harnesses new 
levels of performance for the M68000 Family. 


The superscalar micro-architecture actually 
consists of two distinct parts: a four-stage instruc- 
tion fetch pipeline (IFP) responsible for accessing 


the instruction stream and dual four-stage operand 
execution pipelines (OEPs) which perform the ac- 
tual instruction execution. These pipeline struc- 
tures operate in an independent manner with a FI- 
FO instruction buffer providing the decoupling 
mechanism. A branch cache minimizes the latency 
effects of change of flow instructions by allowing the 
IFP to detect changes in the instruction prefetch 
stream well in advance of their actual execution by 
the OEPs. 


The 68060 is a full internal Harvard archi- 
tecture. The instruction and data caches are de- 
signed to support concurrent instruction fetch and 
operand read and operand write references on ev- 
ery clock cycle. This organization coupled with a 
multi-ported register file provide the necessary 
bandwidth to maximize the throughput of the pipe- 
lines. The operand execution pipelines operate ina 
lock-stepped manner that provides simultaneous, 
but not out-of-order, program execution. The net 
result is a machine architecture invisible to existing 
applications providing full support of the M68000 
programming model including precise exceptions. 


The 68060 external bus interface provides a 
superset of 68040 functionality. Maintaining 32-bit 
widths on both the address and data bus as well as 
a bursting protocol for cacheable memory, the 
68060 supports transfers of one, two, four, or 16 
bytes in a given bus cycle. The system designer 
can, however, choose to operate in one of two 
modes: a mode compatible with the 68040 proto- 
col or anew mode consistent with higher frequency 
bus designs. By allowing this choice, the 68060 
can easily fit into upgrades of existing designs as 
wellas newhigh frequency implementations. 


Pipeline Organization 


The IFP is responsible for prefetching instruc- 
tions and loading them into the FIFO instruction 
buffer. One key aspect of the design is the branch 
cache, which allows the IFP to detect changes in 
the instruction stream based on past execution his- 
tory. This allows the IFP to provide a constant 
stream of instructions to the instruction buffer to 
maximize the execution rates of the OEPs. The IFP 
isimplemented as a four-stage design. 


The four stages of the IFP are: Instruction Ad- 
dress Generation (IAG), Instruction Cache (IC), In- 
struction Early Decode (IED) and Instruction Buffer 
(1B). The instruction and branch caches are in- 
tegral components of the IFP. 


Four operations can be occurring concurrently 
in the IFP. The IAG stage calculates the next pref- 
etch address from a number of possible sources. 
The variable length of the M68000 Family instruc- 
tion set as well as change-of-flow detection make 
this stage critical to the performance of the 68060. 
After the IAG sends the appropriate address.to the 
Instruction cache, the IC stage of the IFP Is respon- 
sible for performing the cache lookup and fetching 


the bit pattern of the instruction. The IED stage of 
the pipeline analyzes the bytes fetched from the in- 
struction stream and builds an extended operation 
word. This lookup stage effectively converts the 
variable-length instruction with multiple formats into 
a fixed-length extended operation word that is used 
by the OEPs in all subsequent processing. At the 
conclusion of the IED stage, the prefetched bytes 
along with the extended operation word issue into 
the instruction buffer The IB stage reads instruc- 
tions from the 96-byte FIFO buffer and loads them 
into the dual OEPs. The FIFO effectively decouples 
the operation of the IFP from the operations of the 
dual OEPs. 


Consecutive instructions issue from the FIFO 
instruction buffer into the instruction registers of the 
dual OEPs. The operand execution pipelines, 
known as the primary OEP (POEP) and the sec- 
ondary OEP (sOEP), are partitioned into a 4-stage 
implementation. The four stages of the OEPs are: 
Decode and Select (DS), operand Address Gen- 
eration (AG), Operand Cycle (OC) and the EXe- 
cute cycle (EX). For instructions writing data to 
memory, there are two additional pipeline stages: 
the Data Available (DA) and Store (ST) cycles. 


The Decode and Select stage of the OEPs 
provides two primary functions: this stage deter- 
mines the next state for the entire operand pipeline 
and selects the components required for operand 
address calculation. To determine the next state of 
the OEPs, the DS cycle logic tests the extended 
operation words to ascertain the number of instruc- 
tions that can issue into the AG stage. If multiple 
instructions can issue into the AG stages in parallel, 
the first and second instructions move into the 
respective AG stages. If only a single instruction 
can issue because of architectural constraints, the 
first instruction issues into the pOEP, and the DS 
stage evaluates the second and third instructions 
as a pair during the next clock cycle. The net effect 
isasliding 2-instruction window to examine possible 
pairs of Instructions for paralle! execution, A dedi- 
cated adder located in the AG stage sums the 
three components of the effective address: the 
base, the index and the displacement. 


The Operand Cycle (OC) of the OEPs performs 
the actual fetch of operands required by the in- 
struction. For memory operands, the OEP ac- 
cesses the data cache in this cycle to retrieve the 
data. For register operands, the OEP accesses the 
register file containing all the general-purpose re- 
gisters during the OC stage. At the conclusion of 
the OC cycle, the execute engines receive the re- 
quired operands. The EXecute cycle (EX) performs 
the operations required to complete the instruction 
execution including updating the condition codes. 
If the destination of the instruction is a data or an 
address register, the result is available at the end of 
the EX stage; if the destination is a memory loca- 
tion, the operation requires two additional cycles. 
First, there Is a Data Available (DA) stage where the 
destination operand issues to the data cache, 


which aligns the operand. Second, updates to the 
data cache occur during the STore (ST) cycle. 
Additionally, there is a four longword FIFO write 
buffer that is selectable on a page basis and serves 
to decouple the operation of the OEPs from ex- 
ternal bus cycles. 


Since this is an order-two superscalar machine 
(dual instruction issue), the sOEP is conceptually a 
copy of the pOEP. A notable exception to this 
concept is the fact that the sOEP executes only a 
subset of the complete instruction set. As an ex- 
ample, the floating point execute engine resides on- 
ly inthe pOEP. Consequently, all floating point in- 
structions must execute only the pOEP. As instruc- 
tions travel down the OEPs, they remain lock- 
stepped. This insures that there is no out-of-order 
execution and thus greatly simplifies support for the 
precise exception model of the M68000 Family. 
The micro-architecture of the 68060 supports a 
number of optimizations to increase the number of 
superscalar instruction dispatches. In internal 
evaluations of traces from existing object code to- 
taling several billion instructions, 50% to 60% of in- 
structions execute as pairs. 


From the preceding discussion concerning the 
operand pipeline stages, all data cache read refer- 
ences occur in the OC stage while data cache 
write references occur in the ST stage. The data 
cache uses a 4-way interleaving scheme to allow 
simultaneous operand read and write operations 
from both OEPs. The data cache directories are a 
single-ported design. As a result, within a super- 
scalar pair of instructions, the 68060 only allows a 
single operand memory reference. The data cache 
also supports single-cycle references of 64-bit dou- 
ble-precision floating-point operands. 


A common drawback to long pipelines is the 
penalty associated with refilling the pipeline when a 
change of program flow occurs. Condition code 
evaluation occurs in the EX stage, but waiting for a 
branch Instruction to reach this point needlessly re- 
stricts performance. Instead, the 68060 contains a 
256-entry Branch Cache (BC) which predicts the 
direction of a branch based on past execution his- 
tory well in advance of the actual evaluation of 
condition codes. 


The BC stores the Program Counter value of 
change-of-flow instructions as well as the target 
address of those branches. The BC also uses 
some history bits to track how each given branch 
instruction has executed in the past. The 68060 
checks the BC during the IC stage of the IFP, the 
same stage that performs the lookup into the In- 
struction Cache. If the BC indicates that the in- 
struction is a branch and that this branch should be 
predicted as taken, the IAG pipeline stage is up- 
dated with the target address of the branch instead 
of the next sequential address. This approach, 
along with the instruction folding techniques that 
the BC uses, allow the 68060 to achieve a zero- 
clock latency penalty for correctly predicted taken 


branches. 


lf the BC predicts a branch as not-taken, there 
is no discontinuity in the instruction prefetch 
stream. The IFP continues to fetch instructions se- 
quentially. Eventually, the not-taken branch in- 
struction executes as a single-clock instruction in 
the OEP, so correctly predicted not-taken 
branches require a single clock to execute, These 
predicted as not-taken branches allow a super- 
scalar instruction dispatch, so in many cases, the 


next instruction executes simultaneously in the 
sOEP, 


The 68060 performs the actual condition code 
checking to evaluate the branch conditions in the 
EX stage of the OEP. If a branch has been mis- 
predicted, the 68060 discards the contents of the 
IFP and the OEPs, and the 68060 resumes fetching 
of the instruction stream at the correct location. To 
refill the pipeline in this manner, there is a seven- 
clock penalty for a mispredicted branch. If the BC 
correctly predicted the branch, the OEPs execute 
seamlessly with no pipeline stalls. Internal studies of 
the prediction algorithm used on the 68060 show 
greater than 90% accuracy from statistics gath- 
ered from several billions of instructions from appli- 
cations across many runtime environments. 
Floating Point Unit 


The floating point unit (FPU) of the 68060 
provides complete binary compatibility with pre- 
vious M68000 Family floating point solutions. The 
68060 performs all internal operations in 80-bit ex- 
tended precision and completely supports the IEEE 
754 floating point standard, 


Conceptually, the FPU appears as another 
execute engine in the EX stage of the pOEP. A 64- 
bit data path between the data cache and the FPU 
optimizes the FPU for single-cycle references of 32- 
or 64-bit memory operands. As previously noted, all 
floating point instructions must execute through the 
pOEP. However, integer instructions can be simul- 
taneously dispatched into the sOEP with most FPU 
instructions, and the 68060 supports overlap be- 
tween the integer execute engines and the FPU. 
Once a multi-cycle FPU instruction is dispatched, 
the pOEP. and sOEP continue to dispatch and 
complete integer instructions (including change-of- 
flow instructions) until another FPU instruction is 
encountered. At this point, the OEPs stall until the 
FPU execute engine is available for the next in- 
struction. 


The FPU's internal organization consists of 
three units: the adder, the multiplier and the 
divider. The 68060's design does not support con- 
current floating point execution; only one of these 
functional units is active at a time. Table 1 show 
execution times for the 68060 FPU. 


Instruction CPU Clocks 
FMOVE 1 


FADD 3 


FMUL 4 
FDIV 24 
FSQRT 66 


Table 1 - 68060 Floating Point Execution Times 
Pipeline Example 


An example of the 68060 pipeline operation is 
the code (not shown) which comes from a com- 
mercially available compiler and represents the in- 
ner SAXPY loop from the matrix300 program from 
the SPEC89 benchmark suite. Since the OEPs are 
decoupled from the IFP, this example only focuses 
on the OEPs. This loop executes 13 instructions in 
only ten clock cycles, producing a steady-state 
performance of 0.77 clocks per instruction (CPI). 
This code includes two multi-cycle FPU instructions 
(4-cycle FMUL and 3-cycle FADD), but the super- 
scalar micro-architecture is able to effectively ex- 
ploitthe parallelism within the loop to achieve a less 
than one CPi measure. 


This example code loop demonstrates several 
major architectural features of the 68060, Of the 
13 instructions, the 68060 dispatches four groups 
of 2-instruction pairs (at cycles 1, 2, 4, 5), one group 
of three instructions (at cycle 9) and two individual 
instructions (at cycles 3 and 8). At cycle 3, the pair 
of instructions being examined is {pOEP = Isl.l, 
sOEP = fadd.d}. Since all floating-point instructions 
must issue into the pOEP, the fadd.d does notissue 
into the sOEP. On the next cycle, a new 2- 
instruction pair is examined {pOEP = fadd.d, sOEP 
= add.|}, and at this time, both instructions issue 
down the OEPs. At cycles 6 and 7, the pipeline 
stalls on the fadd.d instruction as the 4-cycle fmul 
completes execution. The floating-point store 
operation at cycle 8 inhibits any sOEP dispatch be- 
cause of certain post-exception fault possibilities. 
At cycle 9, an instruction triplet is dispatched {add.|, 
subq.|, bec.b}. Recall the branch cache utilizes 
various instruction folding techniques that effec- 
tively allow this predicted as taken branch to exe- 
cute in O cycles. Finally, at cycle 10, the pipeline 
Stalls for one clock on the floating-point store in- 
struction as it waits for the completion of the three- 
cycie fadd. 


Power Management On Chip 


With 2.4 million transistors operating at fre- 
quencies of 50 MHz and higher, power manage- 
ment becomes a crucial issue on the 68060. Fram 
the inception, the 68060 focused on minimizing 
chip-level power dissipation. There are primarily 
three different areas of interest for power dissipa- 
tion. 


The 68060 operates from a 3.3 volt power 
supply. Since power dissipation is a function of the 
Square of the power supply voltage, simply chang- 
ing the power supply voltage to 3.3 volts results in 
a 56% reduction in power compared to a 5 volt 
power supply. In addition to a lower supply voltage, 


the 68060 is a completely static design. The 
68060's operating frequency, which linearly affects 
chip-level power dissipation, can vary dynamically 
down toward the DC range. Although the 68060 is 
a 3.3 volt part, its 1/O buffers interface to either 3 
volt or 5 volt peripherals and memory, facilitating 
upgrades of existing designs. 


Sophisticated power management circuitry on 
chip dynamically controls and minimizes power 
consumption. This circuitry selectively updates 
modules on the 68060 on a clock-by-clock basis, 
dynamically shuttung off the circuits not required to 
support the activities in the current clock cycle. 
Entire areas of the 68060 can shut off for long peri- 
ods of time when they are not required. 


The 68060 also incorporates the LPSTOP in- 
struction. This instruction effectively puts the 
68060 into a low-power sleep mode in which it stays 
until awakened by an externally generated inter- 
rupt. Data on previous members of the M68000 
Family shows that use of the LPSTOP instruction 
can extend battery life in portable applications by 
over 250%, 


Summary 


The 68060 relies on new as well as standard 
architectural techniques to extend the perfor- 
mance of the M68000 Family product line. Perfor- 
mance simulations predict that between 3 and 3.5 
times a 25 MHz 68040 are possible using existing 
object code, 


The 68060 relies on a deep internal pipeline 
and a superscalar internal architecture coupled 
with 8 Kbyte instruction and data caches, a 256- 
entry branch cache, on-chip MMUs and an on-chip 
FPU to bring new levels of performance to the 
M68000 Family architecture. 


Power management is very important on the 
68060, and this design uses dynamic power man- 
agement techniques to minimize power consump- 
tion. The 68060 operates from a 3.3 volt power 
supply, which greatly reduces its power dissipation. 
Although the 68060 operates at a lower operating 
voltage, it interfaces to both 3 volt and 5 volt per- 
ipherals and logic. 


In addition to providing full application object 
code compatibility with previous CPUs in this family, 
the 68060 provides a superset of 68040 hardware 
functionality. Designs compatible with existing and 
future 68040 systems are simple, and higher fre- 
quency designs are possible using a new bus inter- 
face protocol. 
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Sinclair Notes 


If you have something that you feel we should pub- 
lish write to the editor at the Ramtop. We need con- 
tributions from our readers. 


Spectrum Resources 

Keith Turner informs us of one firm which still sells 
new Spectrums and Sinclair stuff. That is W.N-Ri- 
chardson & Co (EEC), 18-21 Misbourne 
House, Chiltern Hill, Chalfont St Peter, 
Bucks, SL9 9UE, England. If you are visiting the 
UK or have a friend there you can probably get one 
second hand for less than fifty pounds. Keith found 
the best place to find one is a computer small ads 
paper such as Micro Mart, which is published on 
Thursdays by MicroMart (UK) Ltd, 24 Rich- 
mond Road, Olton, Solibull, West Midlands, 
B92 7RP, England. The Spectrums in a recent 
Micro Mart included a 48, a 128+, and a +2 with 
monitor and 3.5 diskette drive, all for less than fifty 
pounds each. It would be worth scouring this maga- 
zine for Spectrum add-ons 
while they are still available 
too. 


Spectrum History 
Remembered 

The Spectrum range started 
with the cute little 16K and 
48K slabs with the rubber 
keys. The next release was 
the 48+, which was no 
more than a 48 with the 
original ROM (it isn’t cer- 
tain that the PCB was dif- 
ferent from the later 48s) 
and precisely 3 noticeable 
changes - a QL style key- 
board, a reset button (on 
the side of the case, with 
flying leads messily sol- 
dered across the reset cap) and a much more insult- 
ing user manual. (Annoyingly, the joystick port 
doesn’t properly connect due to the squarer, thicker 
case shape.) 


sage ee Hs : 
members above 


Then came the 128. This was a real advance, with a 
GI sound chip, bank switched RAM and an ex- 
tended basic, not to mention some interfacing capa- 
bilities (rather rudimentary serial and keypad ports, 
starting Sinclair’s trend for BT jacks which was 
continued with the QL). It was still compatible with 
48 software and it was quite a nice &-bit machine, 
and as far as the Spectrum was ever taken. 


After the onset of Amstrad, we had the originally 
titled Spectrum +2, effectively a 128 in a different 
case, similar to the Amstrad CPC range, with a cas- 
sette deck to the right of the keyboard operated by 
keyboard- style keys. The keyboard itself was still of 
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Forth for the OL 


by Dirk Kutscher % MAUS HB2 


| have ported the Unix version of TILE-forth by Mi- 
kael Patel to QDOS. The files (two zoo archives, 
300k together) can be downloaded from 
sabrina.dei.unipd.it. Maus users will find it on the 
next RING’ and on HB2.MAUS bbs. 


Here are some extracts of one of the documenta- 
tion files. (Don’t expect a concise 4th-system - it’s 
rather what | would call a monster.) But you can do 
interesting things with it. Because the threading 
systems extends the standard forth model and 
adds more features than the usual ‘immediate’ flag 
such as 'private’ or compilation’ it enables you to 
treat vocabularies as abstract data types. Most in- 
teresting are the belonging lib-files which contain 
various extensions such as multi-tasking with con- 
dition queues, semaphores, channels and rendez- 
VOUS... 


THREADED INTERPRETIVE LANGUAGE 
ENVIRONMENT (TILE) FORTH RELEASE 
2.1, August 20, 1990 Mikael R.K. Patel 
Computer Aided Design Laboratory (CAD- 
LAB) Department of Computer and Informa- 
tion Science Linkoping University S-581 83 
LINKOPING SWEDEN Email: mip@ida_.liu.se 


1. INTRODUCTION 

TILE Forth is a 32-bit implementation of the Forth- 
83 Standard written in C. Thus allowing it to be ea- 
sily moved between different computers compared 
totraditional Forth implementations in assembly. 
Most Forth implementations are done in assembly 
to be able to utilize the underlying architecture as 
optimal as possible. TILE Forth goes another direc- 
tion. The main idea behind TILE Forth is to achieve 
a portable forth implementation for workstations 
and medium size computer systems so that new 
groups of programmers may be exposed to the fla- 
vor of an extensible language such as Forth. 


The implementation of TILE Forth is selected so 
that, in principle, any C-level procedure may be- 
come available on the interactive and incremental 
forth level. Other models of implementation of a 
threaded interpreter in C are possible but these are 
notas flexible. 


TILE Forth is organized as a set of modules to allow 
the kernel to be used as a general threading engine 
for C. Environment dependencies such as memory 
allocation, error handling and input/output have 
been separated out of the kernel to increase flexibil- 
ity. The forth application is "just" an example of how 
to use the kernel, 


Comparing forth implementations using the tradi- 
tional benchmarks such as the classical sieves 
calculation is difficult because of the difference in 


speed between workstations and personal com- 
puters. The Byte sieves benchmark is reported to 
typically run In 16 seconds on a direct threaded 
forth implementation. This benchmark will run in 17 
seconds in TILE forth (compiled with GNU CC and 
optimized) on a SUN-3/60 and less than 9 seconds 
on a SUN SPAR Cstation 1, These times are the to- 
tal time for loading TILE forth, compiling and execut- 
ing the benchmark. Comparing to, for instance, 
other interpretive languages such as Lisp, where 
one of the classical benchmarks is calculation of 
the Fibonacci function, the performance increase is 
over a magnitude. 


The kernel supports the Standard Forth-83 word 
set except for the blocks file word set which are not 
used. The kernel is extended with many of the con- 
cepts from modern programming languages. Here is 
a list of some of the extensions; argument binding 
and local variables, queue management, low level! 
compiler words, string functions, floating point num- 
bers, exceptions and multi-tasking. The TILE Forth 
environment also contains a set of reusable source 
files for high level multi-tasking, data description and 


structuring modules, and a number of programming 
tools....... 


2. EXTENSIONS 

What is new in TILE forth? First of all the overall 
organization of words. To increase portability and 
understanding of forth code modules vocabularies 
are used as the primary packaging mechanism. 
New data types such as rational and floating point 
numbers are implemented in separate vocabularies. 
The vocabularies act as both a program module 
and an abstract data type. 


2.1 Extensible interpreter 

To allow extension of the literal symbol set (normally 
only integer numbers) each vocabulary is allowed to 
have a literal recognition function. This function is 
executed by the interpreter when the symbol 
search has failed. The literal recognizer for the forth 
vocabulary Is "?number*. This simple mechanism 
allows modules such as for rational and floating 
point numbers, and integer ranges to extend with 
their own literal function. 


2.2 Data description 
As the Forth-83 Standard lack tools for description 
of data structures TILE Forth contains a fairly large 


library of tools for this purpose, These are described 
more in detail in the next section. 


2.3 Argument binding and local variables 
When writing a forth function with many arguments 
stack shuffling becomes a real pain. Argument bind- 
ing and local variables is a nice way out of these 
situations. Also for the new-comer to Forth this 
gives some support to this at first very cryptic 
language. Even the stack function may be rewritten 
using this mechanism: 


:2drop{ab}; 
:eswap{abcd}cdab |; 


‘fac {n}n0> ifn 1-recurse n * else 1 then ; 


The argument frame is created on top of the pa- 
rameter stack and is disposed when functions is ex- 
ited. This implementation style of reduces the cost 
of binding as most functions have more arguments 
then return values. A minimum number of data ele- 


ments have to be move to create and manage the 
argumentframe. 


2.4 Exception handling 

Another extension in TILE Forth is exception han- 
dling with multiple exception handling cade block. 
The syntactical structure is very close to that of 
Ada, i.e., any colon definition may contain an error 
handling section. Should an error occur during the 
execution of the function the stack status is restore 
to the situation at the call of the function and the 
latest exception block is executed with the signal or 
exception as a parameter; 

exception zero-divide (-- exception) 

‘div (xy -- 2) / exception> (x y signal -- ) 
drop zero-divide raise : 


Error situations may be indicated using an excep- 
tion raise function. Low level errors, such as zero 
division, are transformed to exceptions in TILE 
Forth. 


2.5 Entry visibility and forward declaration 
Last, some of the less significant extension are for- 
ward declaration of entries, hidden or private en- 
tries, and extra entry modes. Forward declaration of 
entries are automatically bound when the entry is 
later given a definition. Should a binding not exist at 
run-time an error message is given and the com- 
putation is aborted, 


forward eval (...) 
vapply (...)...eval...;:eval(...)... apply... ; 


Three new entry modes have been added to the 
classical forth model (immediate). These allow hid- 
ing of entries in different situations. The first two 
marks the last defined words visibility according to 
an interpreter state. These two modifiers are called 
‘compilation® and “execution and are used as 
"immediate’. A word like "if is "compilation im- 
mediate" meaning it is visible when compiling and 
then always executed. 


compiler forth definitions 
: if (--) compile (?branch) >mark ; compilation im- 
mediate 


The "private" modifier is somewhat different. It con- 
cerns the visibility across vocabularies (modules 
and types). If a word is marked as "private" the 
word is only visible when the vocabulary in which it 
is defined in is ‘current’. This is very close to the 


concept of hidden in modules and packages in ° 


Modula-2 and Ada. 
4field +name (entry -- addr) private 


The above definition will only be visible in the 


vocabulary it was defined. The "private" modifier is 
useful to help isolate implementation dependencies 
and reduce the name space which also increases 
compilation speed. ... 


3. SOURCE LIBRARY 

The TILE Forth programming environment contains 
a number of tools to make programming in Forth a 
bit easier. If you have GNU Emacs, TILE Forth may 
runin aspecialized forth-mode. This mode supports 
automatic program indentation (pretty printing), 
documentation search, and interactive and incre- 
mental program development, or “edit-compile- 
test* style of program development. 


To aid program development there is also a source 
code library with manual pages, documentation 
(glossary), and test and example code, Most of the 
source code are data modeling tools. In principle, 
fram bit field definition to abject oriented structures 
are available. The source code library also contains 
deougging tools for tracing, break- pointing and 
profiling of programs. 


The first level of data modeling tools are modules for 
describing; 1) bit fields, 2) structures (records), 3) 
aggregates of data (vectors, stacks, buffers, etc), 
4) high level data objects (lists, sets, etc), and last, 
5) object oriented programming with the three ma- 


jor models (relations, prototypes, and classes/in- 
stances). 


The next level of tools are some tools for high level 
syntactic sugar for multi-tasking concepts (sema- 
phores, channels, etc), anonymous code block 
(blocks), a general top down parser with backtrack 
and semantic binding, and a simulation package. 
The source library will be extended during the com- 
ing releases. 


4. PROGRAMMING STYLE 

5. SOURCE FILES 

The TILE Forth source is broken down into the fol- 
lowing files: 

README This short documentation of TILE. 
COPYING The GNU General Public License. 
INSTALL Some help on how to install TILE Forth. 
PORTING Some help on how to port TILE Forth 
andtypical problems. 

Makefile Allows a number of compilation styles 
for debugging, profiling, | sharing etc. New ma- 
chines and conditional compilation symbols are 
added here. 

src TheC source library with the kernel code and 
GNU Emacs forth-mode E-lisp source.?7? 

lib The Forth-83 source library for data descrip- 
tion and management, high level tasking, etc. 

tst Test and example file for each Forth-83 
source code file andaset of benchmarks. 

man Manual pages for the TILE Forth C kernel 
and Forth-83 source code library. 

doc Documentation and glossaries for each 
source code file and kernel vocabularies (gener- 
ated by make help commana). 

bin Utility commands and the TILE forth 


ener gape ee 


compiler/interpreter. 


6. CONFIGURATION 7. COPYING 
This software is offered as shareware. You may use 
itfreely, but if you do use it and find it useful, you are 
encouraged to send the author a contribution (>= 
$50) to the following address: 


TILE Technology HB Stragatan 19 S-582 67 
Linkoping SWEDEN 


lf you send me a contribution, | will send you the 
manual pages and documentation files (and paper 
copies if you don't have access to a good laserprin- 
ter), and will answer questions by mail. Your name 
will also be put on a distribution list for future re- 
leases. 


Notes Continued 


membrane construction, but had a more typewriter 
like quality thanks to it’s raised keys. There were 2 
releases, the +2 and the +2a, which had a minor bug 
fix, something to do with the tape deck. Both of 
these machines had the nice interfaces on the 128 
removed and replaced with a couple of Amstrad 
joystick ports, which, needless to say, were incom- 
patible with everyone else’s. The +2a was a +3 with- 
out a disc drive. It had the black case instead of the 
+2 grey one. The main interface port was different, 
which meant some incompatibility with peripherals 
and software. 


The final "official" Spectrum (rather than semi- 
clones built both in the UK and the USSR) was the 
+3, which continued the descent into Amstraddom 
by adding the 3” drive from the CPC6128 where the 
tape drive in the +2 went. The 3" format had the 
dual disadvantages of the lack of use by other manu- 
facturers (and where it was used, it was used in a 
different and usually better way), and the lack of an 
existing software base in that format, and so the sys- 
tem was generally found to be a lot less useable than 
existing OEM external drives, which usually provide 
“snapshot” capabilities. 


Publish and Perish 

Pete Collier reports that both Your Sinclair & Sin- 
clair User are dead. Both died early on in 1993. Sin- 
clair User had teamed up with Crash, but they still 
couldn’t survive. Your Sinclair did much better, but 
once the big names (Ocean, US Gold, Gremlin, 
Virgin) pulled out of the 8 bit market, they had no 
new games to review and perished within months. 


A number of Sinclair newsletter/fanzines have 
started up and one of these is called ZAT which is 
being published bi-monthly. If anybody wants more 
info on it, send an SAE with 2 international reply 
coupons (available at your local post office) to 
ZAT,33 Dawley Bank, Dawley, Telford, 
Shropshire, TF4 2LQ. 


What ever happened to Uncle Clive ? 

Not having heard from Uncle Clive lately and not 
having seen him with Don King, some may have 
thought his picture would soon be seen at breakfast 
on a milk carton. Good news! Apparently Sir Clive 
and his son are running a mail order company for 
PC stuff. According to Scott Teleford of the the 
University of Edinburgh, Clive and his son, Crispin, 
have set up a company called Sinclair Games, which 
sells discount PC games, software, joysticks, and the 
usual stuff, by mail order. Clive is a company direc- 
tor. There’s a rather cheesey full page ad in last 
month’s PC Review magazine (the one with the 
Frontier review and the pink cover), and probably 
in other PC games mags too. 


Another Blast from the Past 
For 1K programmers, do you remember these memo- 
ry saving tricks: 


number bytes solution bytes 
0 6 SIN PI z 
1 6 SGN PI 2 
-1 th COS PI 2 
3 6 INT PI 2 
100 8 VAL "100" 6 


Another thing that you can use these tricks for to 
save space is to define a variable with them. Of 
course we all remember how to use "VAL". One 
space saver that you may not remember is using the 
CODE function which will work with characters and 
keywords from 32 to 255. Just define a variable 
like Let A=Code "z" makes A have a value of 122. 
Another way to write large numbers is to use VAL 
but in the E form of the number. An Example would 
be Let a=VAL"1E5" (1 and 5 zeros or 100000). Jim 
Showalter used this technique in his Strip Poker 
program for the 2068. 


If you have access to internet the address of the sin- 
clair sig from which most of the above information 


has come is sincnews@psg.com. Thanks to Doug 
Gillespie for the raw data. 


President’s Message 


Hello to you all! I cer- 
tainly hope you have 


able cold weather! 
(Back in January wheng 
this article was i 


fairly lucky so far. 
Having an outside job 
in this cold is no fun! 
The Christmas meetin 
was a big success! 
There were a lot 
faces we have not see 
in quite a while. Some 
of these include: Dale Sincovick, Jim Lewis, Ron 
Lutz, Dave Hoshor, Andy Korsorik, and others. 
Lots of good stuff was for sale and I bought some of 
it. Thanks to all of you for coming! I hope you 
won't be strangers and see us more often! 


Let’s move on to the subject of our meetings. We 
have become so informal that we really don’t have 
any structure at all. This is mostly my fault. I would 
like to improve on this in the future. We should al- 
ways have a treasury report and give each member a 
chance to bring in some new information or some- 
thing of interest. Also, we really need to have some 
schedule for demos. Demos can be on almost any- 
thing as long as it is computer related in some way. 
I also have been thinking that since almost all of us 
now have IBM clones that maybe we should change 
the name of our club to reflect this. I would like for 
each of you to give your opinion of this. If you like 
the idea, think of a name and let's discuss it in a 
month or two. That’s about it for now. Take care 
till next time! 


A User’s Guide To 
Computer | 


Terminology 
B 
Sdsete Cohen 


Beginner: A person who believes more than one- 
sixteenth of a computer salseperson’s spiel. 


Advanced User: A person who has managed to 
remove a computer from its packing materials. 


Power User: A person who has mastered the 
brightness and contrast controls on any computer's 
moniter. 


Sales Associate: A former cheese-monger who 
has recently traded mascarpone for MS-DOS 


Loading Spectrum 
Programs to your PC with 
the Sound Blaster 


By Tomi Edgehill 


The following information can be found from book 
"An Expert Guide to the Spectrum" written by Mike 
James and published by Granada. Text is also result 
of my experiments. 


Spectrum casette file consist of two parts: header 
part and the actual file part. Both parts have same 
basic structure: first there is loader tone, then a syne 
pulse and after it the actual data. 


Loader tone signal signal is 614.9 microsecond 
low and 614.9 microseconds high. The sunc pulse is 
190.6 microseconds low and 210 microseconds 
high. In data part one bit is 488,6 microseconds 
low and 488.6 microsecons high. Zero bit is 244.3 
microseconds low and 244.3 microsecond. 


The data is stored so that most significant bit of 
byte is saved first and least signicant bit last. The 
first byte of the data part of file tells the type of file 
and the actual data follows after it. The last byte in 
data part is cheksum which is obtained by xoring all 
data bytes together. 


And here is a simple Turbo Pascal program which I 
have used to load files from spectrum tapes. It 
works nicely when Spectrum is directly connected 
to SoundBlaster and I save file in spectrum and 
start that loading program in PC. With casette deck 
test have been less succesful. The program loads on- 
ly the header part, but can be easily extended. 
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Sales Manager: Last week's new sales associate. 


Consultant: A former sales associate who has mas- 


tered at least one tenth of the D-BASE 3 Plus Man- 
ual. 


Systems Integrator: A former consultant who 
understands the term "AUTOEXEC.BAT". 


Service: Cursory examination, followed by the 
utterance of the phrase "It can’t be ours" and either 
of the words "hardware" or "software." 


Support: The mailing of advertising literature to 
customers who have returned a registration card. 


Alpha Test Version: Too buggy to be released to 
the paying public. 


Beta Test Version: Still too buggy to be re- 
leased. 


Release Version: Alternate pronounciation of 
"beta test version." 


Enhanced: Less awful in some ways than the pre- 
vious model, and less likely to work as expected. 


Upgraded: Didn’t work the first time. 


Upgraded and Improved: Didn't work the sec- 
ond time. 


Memory-Resident: Ready at the press of a key to 
disable any currently running program. 


Multitasking: A clever method of simultaneously 
slowing down the multitude of computer programs 
that insist on running too fast. 


Encryption: A powerful algorithmic encoding 
technique employed in the creation of computer 
manuals. 


Desktop Publishing: A system of software and 
hardware enabling users to create documents with a 
cornucopia of typefaces and graphics and the in- 
tellectual content of a Formica slab; often used in 
conjunction with encryption. 


High Resolution: Having nothing to do with 
graphics on an IBM-compatible microcomputers. 


FCC-Certified: Guaranteed not to interfere with 
radio or television reception until you add the 
cable required to make it work. 


American: Italian or Taiwanese, as in "American 
Telephone and Telegraph." 


American-Made: Assembled in America from 
parts made abroad. 


Windows: A slow-moving relation of the rodent 
family rarely seen near computers but commonly 
found in specially marked packages of display 
cards, turbo cards, and Grape-Nuts Cereal. 


TopView: The official position of IBM brass that 
an abysmally slow character-based multitasking 
program is the product of the future. 


DGS-SHELL: An educational tool forcing com- 
puter users to learn new methods of doing what 
they already can. 


UNIX: Sterile experts who attempt to palm off 
bloated, utterly arcane, and confusing operating 
systems on rational human beings. 


EMS: Emergency Medical Service; often sum- 
moned incases of apoplexy induced by attempts to 
understand extended, expanded, or enhanced 
memory specifications. 


Videotex: A moribund electronic service offering 
people the privilege of paying to read the weather 
on their TV screens instead of having Willard Scott 
read it to them free while they brush their teeth. 


Artificial Intelligence: The amazing, human- 
like ability of a computer program to understand 
that the letter y means "yes" and the letter n means 


nn nn 


no 


Electronic Mail: A communications system with 
built-in delays and errors designed to emulate 
those of the United States Postal Service. 


Turbo Card: A device that increases an older- 
model computer’s speed almost enough to compen- 
sate for the time wasted in getting it to work. 


Laser Printer: A xerographic copying machine 
with additional malfunctioning parts. 


Workstation: A computer or terminal slavishly 
linked to a mainframe that does not offer game 
programs. 


RISC: The gamble that a computer directly compat- 
ible with nothing else on the planet may actually 
have decent software written for it someday. 


AU TOEXEC.BAT: A sturdy aluminum or wooden 
shaft used to coax AT hard disks into performing 
properly. 


Plotter: A terroristic hypodermic device used to 
inject graphic representations of boring data into 
boring meetings. 


Clone: One of the many advanced-technology 
computers IBM is begining to wish it had built. 


CD-ROM: An optical device with storage suffi- 
cieent to hold billions of predictions claiming it 
will revolutionize the information industry. 


IBM Product Centers: Historical landmarks for- 


ever memoralizing the concept of “list price on- 
ly." 


IBM: Somewhat like an IBM preduct; in current 


parlance, invariably followed by the word "compat- 
ible." 


Fully IBM Compatible: Somewhat IBM compat- 
ible, but won't run IBM BASIC programs. 


100% IBM Compatible: Compatible with most 
available hardware and software, but not with the 
blockbusters IBM always introduces the day after 
tomorrow. 


Hard Disk: A device that allows users to delete 
vast quantities of data with simple mnemonic com- 
mands. 


Mouse: A peripheral originally christened "vermi- 
form appendix"because of its functional resem- 
blance, renamed for its appropriateness as a cat 
toy. 

Printer: An electromechanical paper-shredding 
device. 


ax Program Spectrum_to_PC; 


{ Sinclair Spectrum casette loader for IBM PC compatibles 
with Sound Blaster. Sound Blaster must be at default I/0 address 220h. 


i Copyright 1992 Tomi Engdahl 


: Sinclair Spectrum is a registered trade mark of Sinclair Reserch Ltd. 
: Sound Blaster is a register trade mark of Creative Labs Inc. 


,c } 
i Uses crt; 
o 
Var 
timer_count:word; 
tmp: byte; 
old_bit:byte; 
Const 


Timer0=$40; 
TimerCtl r=$43; 
TimerC]k=1193180; 


Audio0=128; 
hysteresis=20; 


mid_value=2000; {2000} 


ltone_HI=4000; 


Procedure CLI; 

Begin 

Inline(S$FA); {cli, disable interrupts} 
End; 


Procedure STI; 

Begin 

Inline(SFB); {cli, enable interrupts} 
End; 


Function TimerORead: word; a 

Var 9 5 
value:word; 

Begin 
Port([TimerCtlr]:=0; {latch timer 0} 
value:=Port[(Timer0]; 
value:=value+(Port[{Timer0] shl 8); 
TimerORead:=value; 

End; 


Function time_difference:word; 

Var value:word; 

Begin 

{R-} 
Port[TimerCtlr]:=0; {latch timer 0} 

value:=Port[Timer0]; 
value:=valuet+(Port[Timer0] shl 8); 
time_difference:=timer_count-value; 
timer_count:=value; 


{R+} 

End; 

Function Read_SBADC:byte; 

Begin 
Inline( 
$BA/$2C/$02/ {MOV DX,022C } 
SEC/ {IN AL,DX } 
$a8/$80/ 2 {TEST AL,80 } 
$75/SFB/ { INZ 0107 } 
$B0/$20/ {MOV AL,20 } 
SEE/ {OUT DX,AL } 
SBA/$2E/$02/ {MOV DX,022E } 
SEC/ {IN AL,DX } 
$A8/$80/ {TEST AL,80 } 
$74/SFB/ {JZ 0112 } 
$BA/$2A/$02/ {MOV DX,022A } 
SEC/ {IN AL,DX } 
$A2/tmp); {MOV a,AL } 
Read_SBADC:=tmp; 

End; 


{Function schmitt_trigger(value:byte) : byte; 

Begin 
If old_bit=0 Then If value>(audioQthysteresis) Then old_bit:=1; 
If old_bit=l Then If value<(audioO-hysteresihen old_bit:=0; 
schmitt_trigger:=old_bit; 

End; } 


Function schmitt_trigger(value:byte):byte; 

Begin 
If old_bit=0 Then If value>(audiod+hysteresis) Then old_bit:=1; 
If old_bit=l Then If value<(audio0-hysteresis) Then old_bit:=0; 
schmitt_trigger:=old_bit; 

End; 
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Function bit_from_tape:byte; 
Var cs 
adevalue:byte; 
count:integer; 
Begin 
Repeat Until schmitt_trigger(Read_SBADC)=0; 
Rei_difference>mid_value Then bit_m_tape:=l 
Else bit_from_tape:=0; 2 
End; 


Procedure Wait_loader_tone; 
Var 
diff:word; 
count:integer; 
Begin 
diff:=0; 
Repeat 
Repeat Until schmitt_trigger(Read_SBADC)=0; 
Repeat Until schmitt_trigger(Read_SBADC)=1; 
diff:=time_difference; 
If (diff>mid_value) and (diff<Ltone_hi) Then Inc(count) 
Else count:=0; 
Until count>=10; 
End; 


{******* High level packet routines ******xxKKEKK } 
Var tavut:array[{0..50000] of byte; 


Procedure load_bytes(maara:word); 
Var 

tavu,p,a,n:byte; 

laskuri:word; 
Begin 

ClrSer; 

Repeat Until bit_from_tape=1; 


{wait for loader tone} 
Writeln('loader tone detected'); 


Repeat Until bit_from_tape=0; {synclse wait} 
{Writeln('sync');} 
For n:=0 to 7 Do p:=bit_from_tape; {over the start byte} 
laskuri:=0; 
Repeat 

tavu:=0; 


For n:=0 to 7 Do tle aces | shl 1)+bit_from_tape; 
tavut[laskuri]:=tavu; & 
Writeln(tavu); 
Inc(laskuri); 
Until laskuri>=maara; 
End; 


Procedure print_header; 
Var a:integer; 
Begin 

Writeln; 

Write('Program: '); 

For a:=l1 to 10 Do 

Begin 

Writhr(tavut[a])); 

End; 

Writeln; 

Writeln('Start: ',tavut([13]+256*tavut[14]); 
Writeln('Length: ',tavut({11]+256*tavut[12]); 
End; 


Procedure header_load; 
Begin 

load_bytes(17); 
print_header; 
End; 


{ #XRRKHKKAEAR Main program ***KRKKKRKKEKE } 


dummy: word; 
Begin 
CLI; 
old_bit:=0; 
dummy :=time_difference; 
Wait_loader_tone; 
header_load; 
STI; 
Repeat Until KeyPressed; 


End. 
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